home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 2513 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: Re: Executive and AmiTCP..
  5. Date: Tue, 27 Feb 96 04:54:52
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960227.4190C0.4F2F@aj169.du.pipex.com>
  9. References: <778.6621T1384T1708@moor.slip.uky.edu> <4gahsu$5fm@tkhut.sojourn.com>
  10. NNTP-Posting-Host: aj169.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Manfred Matzinger (matzing@ping.at) wrote:
  14. : On 26-Feb-96  03:00:25, Mathew Hendry <m.hendry@dial.pipex.com> wrote:
  15. :  MH> No, but many of BlitzBlank's blanker modules are very CPU intensive. If you
  16. :  MH> don't shedule BlitzBlank properly, it's likely to steal a lot of CPU time
  17. : 
  18. : BlitzBlank doesn't steal lots of CPU time, because it installs it's own
  19. : WatchTask, which forces Blitzblank to show a blank, black screen when the
  20. : current blanker-module steals too much CPU time.
  21.  
  22. That doesn't work properly with Executive running.
  23.  
  24. To check CPU usage, BlitzBlank installs a dummy task, called BB.WatchTask, at
  25. the same priority (-5 by default) as that of the chosen blanker module. If
  26. BlitzBlank finds that BB.WatchTask is not getting any CPU time (i.e. some
  27. program(s) at priority -4 or above are using all available CPU) it stops the
  28. blanker module immediately and replaces it with a blank screen.
  29.  
  30. Under Executive this method does not work, because the task priorities are
  31. continually shifted around to give _all_ tasks some CPU time - that is the
  32. point of using a sheduler, after all.
  33.  
  34. So BB.WatchTask is not blocked, making BlitzBlank think that the system is not
  35. under heavy load. The result of all this is that the blanker module continues
  36. to run, eating up valuable CPU time.
  37.  
  38. : There is no need to schedule any of BlitzBlanks tasks!
  39.  
  40. Yes there is.
  41.  
  42. One way, which still allows BlitzBlank to react to heavy loads, but has a
  43. rather annoying side-effect, is this:
  44.  
  45. BB.WatchTask NOSHEDULE BELOW
  46.  
  47. But...
  48.  
  49. The side effect is that when the screen is unblanked, BB.WatchTask is not
  50. terminated, so you are left with an orphan task which cannot get any CPU
  51. time, yet _needs_ CPU time to quit itself. After a few blank-unblank cycles,
  52. you are left with a load of these neglected orphans, which sends the CPU load
  53. shooting up.
  54.  
  55. The orphans will disappear once the CPU-hogging program goes idle, but having
  56. these useless tasks lying around is a bit wasteful, not to mention irritating.
  57. And if you are running a program which takes a long time to complete, for
  58. example a complex render taking several days, you could have dozens of
  59. BB.WatchTasks lying around by the time it's complete...
  60.  
  61. -- Mat.
  62.